ShowTable of Contents
Disclaimer: IBM Lotus Notes Domino R8.5.3 is pre-release software so there is no guarantee that this will be part of the final release.
What is Single Copy XPages Design
So what is it? Single Copy XPage Design is a new feature in 852 that allows for XPage resources to be shared. XPages design elements (XPages, Custom Controls, CSS, client/server JS libraries, themes) are stored in one database and then other databases can point to this common "SCXD" database through a new database property available in Designer (in the Performance section on the XPages tab in the Application Properties). At runtime, XPages will read this information and, if it is not empty, will then use the design elements from the "SCXD" database instead of the current database. So effectively you have UI in one database and data in another.
Benefits of this new feature
So what are the benefits of this new feature? Being placed under the Performance section in the Application Properties should be a give it away. The benefits are felt at runtime where the browser caching becomes more efficient as the same resources can be served for many separate applications. Rather than having same resources being served from each application which isn't optimal from a browser point of view.
Another benefit is that you can use this feature to your advantage by cutting down on design and admin time required to maintain the same UI across databases.
An example of its use
So let's have an example. Say you've upgraded your Domino server to 852 and on this server you've got some legacy, pre-8.5, applications which you're thinking about upgrading as well as take advantage of this new XPages technology.
Let's take an old application is from an old Discussion template.

And you've also got newer discussion app based upon the 852 template (this is it set to the green theme from oneuiv2).
So in the old app we're going to open the Application Properties in Designer and set the SCXD path to the newer discussion application to use it's XPages design elements.

Both of these applications would have the same forms and views (the newer discussion template has new forms and views which need to be copied over to the pre-85 discussion application to get this scenario to work).
Now hit the old pre-85 app in the browser -
http://yourDomino/oldDisc7App.nsf/allDocuments.xsp
Some limitations to this feature
- A dummy or blank XPage with the same name of the default XPage from the SCXD database is needed to allow it to launch the app as the default XPage.
- The SCXD database has to be a NSF, not an NTF.
- Common 'classic' design elements (Views, Form, Agents...) are needed in both NSFs. Only the XPages design elements can be shared
- The XPages design elements cannot currently be overridden on a per instance basis.
- The Domino server's HTTP task needs to be restarted when the SCXD is set. While this is true in most cases it isn't in the following scenario. If the SCXD database has already been launched in a browser, any browser, other databases can reference this SCXD database without needing a http task restart.
How does SCXD works?
As the "SCXD" database is a real NSF, it is exposed as a J2EE module like any other NSF. But when a request coming to an instance database having the "single copy design" pointing to a "SCXD" database, it is automatically redirected to the "SCXD" module, and no actual module is created for the instance database. As such, the same JSF objects, servlets, J2EE module... are used by all the instances. Simple, the execution context is different for all those requests, exposing some different objects:
The
database object
It points to the instance database, so each instance exposes a different one.
The
applicationScope object
Each instance has its own scope, as this should not collide between the instances. The ServletContext object is having a different collection of attributes per instance, and one applicationScope exists per instance.
The
sessionScope object
Each instance has a session that are isolated from the other instances. HttpSession objects are created per session/instance and isolated from the other instances. This is also true for the sessionScope variable.
FAQ
When changes are made to XPage elements in the SCXD database, are they used?
Making changes in the SCXD database are immediately reflected in the applications using that database.
In Domino R8.5.2, changing design elements in the SCXD database required at minimum a http task refresh on the server. Once this is done these changes would get reflected to the applications which use the SCXD database. This is certainly true in most cases. But if the SCXD database has not been launched by the http task then that task then needs to be restarted on the server.
In R8.5.3, this will change. Here design changes, or even when applications are set to use a SCXD database, don't require a http task refresh. Changes in the SCXD database instantly display in recipient applications.
The wiki article states that database, application and session scope variables are all available per instance, does this mean there are no implications for programmability with regard to SCXD database?
This is correct. It shares the application design, the classloader, but still maintain sessions per databases
Is the list of design elements mentioned in the wiki article complete?
The article lists XPages, Custom Controls, CSS, client/server JS libraries & themes. Should the list include the other members of the resources section in Designer, such as Images, Files etc?
Correct, images would also be also included. Files may depend if they're used by the web application. Certainly files like 'strings.properties' from the discussion template which is used by the XPages application would be included by the SCXD database. It would probably be easier to list out the design element which are not included - Forms, Views, Subforms, Folders, Shared fields and so on - the typical design elements used by conventional Notes databases.
Are there any elements not part of the Designer view, such as java methods that are also included in SCXD?
The APIs are not different between regular NSF and "SCXD". Only the way the classes are loaded and resources are shared actually matters.
Apart from the "dummy or blank XPage with the same name of the default XPage" in each instance application, does it matter if an 'instance' contains XPage design elements?
No. If SCXD is set on an application all XPages design elements are ignored on the database and the application uses the design elements on the SCXD database.
Does SCXD require that all of an application's XPage elements live in one SCXD application or can some (different to those in the SCXD) remain in each instance?
Correct, all design elements must live on the one SCXD database.
If there are Xpage design elements (as listed above) in an instance that uses a SCXD, are they totally ignored or do they still contribute to the application's memory 'footprint' on the server?
They are ignored (not in being used). Only the one in the shared NSF are being loaded and used.
Is it true that selecting or de-selecting SCXD in a template does not propagate to applications already created with that template?
This is not the case. If a template is set to use a SCXD database and an application is created from this template then the new application will have the XPages from the SCXD database. And changing the template to say another SCXD or no SCXD database set will reflect in the database that inherits its design from the template.
Does employing SCXD typically have a positive or negative affect on speed of performance?
From a pure performance standpoint, there is no difference. SCXD initializes new databases faster as the design elements lists, as well as the jva classes, are already loaded. It also helps a lot with memory, which makes it finally faster
Is it recommended or necessary to use a particular style of server page persistence with SCXD to see optimum performance in terms of speed and memory utilisation?
There is no necessary practice associated with using SCXD outside current practice specific to performance. And as with any XPages application's performance and scalability is concerned the developer is recommended to read Chapter 16 of the Mastering XPages book published by IBM Press.
.